While Aruba once again left millions of Italian sites on the ground, VMengine silently migrated, without jolts, without service stoppages, the portal Ninjamarketing.it from a physical server hosted dedicated to an Italian provider, to the clouds of Amazon Web Services.
The Ninjas
Ninja Marketing is the benchmark for innovation in marketing and communication. Founded in 2004 by Alex Giordano and Mirko Pallera, YouTube has been a valuable resource for understanding the changes taking place in the field of marketing and communication, in the technological and social innovation at the basis of the very rapid evolution we are witnessing. Since its foundation in a hidden “lair” on the Amalfi Coast, Ninja Marketing has aggregated a movement of creatives, marketing professionals, students of Communication Sciences, united by the desire to renew the way companies communicate.
In first place among Italian marketing blogs (source Wikio), Ninja Marketing is visited daily by influencers, trend setters, early adopters, in particular entrepreneurs, agency and company managers, PR, journalists, geeks and Web 2.0 enthusiasts.
Requirements
The portal was managed by a single dedicated server and coped with considerable difficulty with traffic of about 175 GB and 250,000 pages per month. The same machine had web service, database, primary and secondary DNS, email server and managed 20 domains, all with about 54 GB of data. Staff and users complained of slowness at certain times and it was often necessary to request a restart of the server to make it resume.
In this condition, the ninja staff, which has a great desire to grow both in terms of traffic and in projects related to the portal, began to evaluate solutions that would unleash their entrepreneurial creativity.
Solution
Our policy is to “transfer” customers to the clouds through a gradual, painless and transparent migration, avoiding service downtime and avoiding as much as possible an increase in customer costs.
The portal falls into the medium-traffic genre, but above all into that kind of portals with great growth potential. The proposal was a migration to Cloud Computing with distribution of services and content and with self-scalability policies, useful for reducing costs in periods and times of less access and providing power only when needed.
The migration consisted of three basic steps:
AWS Services Used:
- Route53
- S3 – CF
- ELB – EC2 – AS – CW
- RDS
- DNS Server Migration
- Contents Migration
- Computing Migration
First of all, take the DNS servers out of the physical machine where all the other services were simultaneously. We moved DNS control to the AWS Route53 service, thus eliminating an initial point of failure and streamlining the physical server by about 50,000 queries /day (on Route53 at a cost of $0.50 per 1 million queries). A fundamental step, moreover, to be able to quickly manage the other two points.
Moving the content (photos, documents, etc.), by transparent copying on the AWS S3/CloudFront CDN, allowed us to easily replace the public link of the content by changing the suffix of the web path from www.ninjamarketing to cdn.ninjamarketing, this brought a lot of breathing space to the physical server now saturated with network and disk I/O access. An additional 135,000 requests/day (on CloudFront at a cost of $0.09 per 100,000 HTTP Req) were transferred to Amazon’s datacenters distributed around the world. The CDN, content delivery network, allows users scattered around the world to be able to use the contents of the portal much faster, as the content caching system “approaches” the user by replicating the photo or document to the edge servers geographically closest to the HTTP request (meaning from a network path point of view).
With the DNS managed via Route53 and the content distributed in S3 / CloudFront, it was only necessary to implement the infrastructure consisting of the AWS ELB Load Balancer, the AMI images of the custom linux web servers, the MySQL RDS database, a Linux Memcached, and a Linux NAS with EBS disk, to share code files and those contents that are not yet distributed or not distributable in CDN, to the various EC2 instances managed by scaling policies and alarms on Cloud Watch.
Benefits
The transition to Cloud Computing brings with it multiple benefits in general, in particular of our solution we have:
- Scalability – Amazon’s datacenters are spread across 5 regions (USA East, USA West, Europe, South Asia, North Asia), with thousands of extremely powerful servers for each region. AWS services allow you to take advantage of this power in an unlimited way, obviously depending on the customer’s financial availability.
- Reliability – Amazon’s systems and datacenters are highly reliable and redundant, but the versatility of their services allows you to plan Disaster Recovery interventions capable of bringing the Ninja portal back to another region in a few minutes, assuming a gigantic hardware failure of an entire datacenter.
- Automatisms – The automatism policies applied to the request for more power or to the request for power release, free from the need to hypothesize traffic growth using systems that are too powerful, or to underestimate its volume, using systems that are insufficient to let in all the users concerned.
They also save costs at times of low traffic (e.g. at night). - Unlimited Connectivity – The gigantic bandwidth opening of all Amazon datacenters are a guarantee regarding unlimited connectivity to the portal. Bandwidth is a cost that is offered on a pay-as-you-go basis to the customer, so Amazon does not limit the maximum cut like many providers without telling the customer.
- World Wide orientation – The distribution of datacenters and edge servers (those of the CDN) eliminate any limitation to the creativity of the customer who can invent projects in a foreign language to be managed remotely from their offices.
- Costs – Our approach is aimed at maintaining or reducing the customer’s overall TCO, therefore a lot of work has been done and will continue to be done to seek the right cost/performance compromise by planning our design and implementation based above all on the costs that the customer previously incurred. Obviously, the solution allows for a greater entry of users, and the cost model is pay-as-you-go, not fixed.